Hey @gferreira, Thank you so much for the fast reply, your code works just as expected!

Thanks so much, @gferreira, this solves it perfectly in SWM!! I wouldn't have figured out setDimension x2 in splitView + centerGlyphInView(). And yes the main tool has fontOverview.views.sizeSlider.set() :)) I've flowed in your solve. Feel free to play with the real tool here.

Current Issue I’ve made a script to toggle between light & dark mode in RoboFont: https://gist.github.com/arrowtype/ce0cee426f47c2fe7e82aa07d1e0a450 However, there is an unfortunate bump in dark mode: markColors that are high-opacity can greatly disrupt the dark palette. That is, I have set up existing UFOs with marks that are opacity=1. However, these colors were selected with a light UI in mind, so they work well when surrounding glyph cell backgrounds are white, but not very well when they are dark. Here's my typical gray for glyphs made from Glyph Construction, disrupting an otherwise dark theme: Glyph marks are much more effective when changed to a lower opacity, about 0.25–0.5. Here are the same marks but at 0.5: Unfortunately, in my darkmode toggle script, the best I can do to get working mark colors for darkmode is to offer to change the opacity of marks if they are above a threshold. However, this requires me to change data in the actual UFO, and doesn’t work automatically for new UFOs I open. Because I have existing marks in many UFOs and don’t want to make meaningless commits, this is unappealing. Worse, for some users, they may have processes or scripts connected to specific glyph mark colors (e.g. a collaborative workflow that relies on different hues or opacities to show what is "done" vs "in progress," perhaps also connected to automatic proofing, etc). Possible Solution If the RoboFont preferences had a setting like glyphCellDisplayedMarkOpacity with a 0–1 value, this problem could be very easily solved. E.g. a glyphCellMaxMarkOpacity of 0.5 would multiply all rendered mark opacities in the glyph view by 0.5. This would enable Font View preferences to be freely adjusted without requiring users to edit the actual mark color information in glyphs. This isn't the only possible solution, but it seems like it might allow the flexibility needed here, with a minimum of additional required preferences for users. Thanks for adding the glyph view preferences! This is a big bonus to an app I use daily. :)

Thanks, @frederik. I understand that, and I believe that it is not the best possible way to display this information, as evidenced by the screenshots in this thread. Specific options for selected background/foreground colors would be helpful, as I suggested above. I really appreciate the big advance you've given the app in the recent option updates! It makes a really big difference in the comfort of using RF in the evening. This is just one area that I believe still requires a little extra advancement to make the "dark mode" mode complete. Thank you!

It was a dig but I got it, in case anyone is following (and sorry for abusing the Robofont UI so much, Frederik): https://gist.github.com/okay-type/e301a1da610bfdbe484787e93f52ef16

oh, idd not working as it should be... will be fixed in next beta/release thanks

Thanks @frederik!

hello @bahman, I gave it a try – this seems to work: from vanilla import Window, List from AppKit import NSDragOperationCopy from lib.settings import doodleSelectedGlyphIndexesPboardType class TestWindow: def __init__(self): self.w = Window((400, 200), 'test') self.w.list = List((10, 10, -10, -10), [], selfApplicationDropSettings=dict(type=doodleSelectedGlyphIndexesPboardType, allowDropOnRow=True, allowDropBetweenRows=True, operation=NSDragOperationCopy, callback=self.selfApplicationDropCallback)) self.w.open() def selfApplicationDropCallback(self, sender, dropInfo): isProposal = dropInfo["isProposal"] if not isProposal: glyphs = dropInfo["data"] source = dropInfo["source"] glyphNames = [source[glyphIndex].name for glyphIndex in glyphs] self.w.list.set(glyphNames) return True TestWindow() but using stuff from the lib is not recommended… maybe @frederik knows a better solution. cheers!

added to the docs as an example. thanks!

Nice, thank you!